編者按：本文作者為Jeff Standen，這是一位有著21年以上經(jīng)驗(yàn)的國外軟件開發(fā)者。如果你覺得他的經(jīng)驗(yàn)比較有益處，可以借鑒一下。
首先開發(fā)spike解決方案 —— 這是我早期敏捷/極限編程所養(yǎng)成的習(xí)慣之一。spike解決方案是一次性原型，可以幫助你在投入大量時(shí)間和精力之前驗(yàn)證你是否走對路。
區(qū)別就在于原型，因?yàn)槟阕裱@樣一個(gè)規(guī)則，在你完成研究之后，你最終會(huì)扔掉“spike”代碼。所以允許你偷工減料，迅速行動(dòng)，因?yàn)樗粫?huì)出現(xiàn)在產(chǎn)品或代碼審查中。
此方法有助于迅速發(fā)現(xiàn)設(shè)計(jì)的哪些部位尚不明確，而不必過早地嘗試架構(gòu)或設(shè)計(jì)決策。
致力于小而連貫代碼塊的版本控制 —— 通過類似CVS/Subversion，每次提交都直接發(fā)送到服務(wù)器。做部分文件的提交并不簡單。
隨著Git的出現(xiàn)，只提交較大文件的若干行代碼變得很容易，并且可以在push到遠(yuǎn)程代碼倉庫之前先本地rebase/merge提交。
有一次，我在工作于更大功能的時(shí)候，采用了小型增量提交，我的工作效率直線上升。這樣做能夠清空我的大腦以便于面對更重要的事情。
經(jīng)常寫代碼 —— 最近，我正工作于：一個(gè)基于Web的企業(yè)協(xié)作和自動(dòng)化平臺（PHP / MySQL），一個(gè)基于云的實(shí)時(shí)指標(biāo)聚合器和使用循環(huán)哈希（Node.js/ Redis）的API，一個(gè)面向iOS app商店（Swift/ SpriteKit）的棋盤游戲，專門的基于URL的cronjob可替代基于web的SaaS服務(wù)（JAVA），等等。
用過大量框架和語言有助于我的抽象和算法思維。
我從工具，如Eclipse RCP、Tapestry和Hibernate中學(xué)到了很多偉大的經(jīng)驗(yàn)教訓(xùn)，并用到我的PHP項(xiàng)目里。尤其是在2000年初，在有Java特征的企業(yè)生態(tài)系統(tǒng)用于PHP存在之前。我從Unity3d/C#學(xué)到了很多關(guān)于網(wǎng)絡(luò)和面向消息的架構(gòu)。
如果我只堅(jiān)持單一平臺和社區(qū)的話，就永遠(yuǎn)不會(huì)知道這些概念。
編寫簡單的代碼 —— 我以前習(xí)慣于寫復(fù)雜的代碼以作為對自己的挑戰(zhàn)。而現(xiàn)在的挑戰(zhàn)是要編寫優(yōu)雅且簡單的代碼——到一種每個(gè)人都覺得他們也能做到的地步（即使他們不能）。簡單代碼通常來自于若干次復(fù)雜代碼的迭代。
引用Antoine de Saint Exupéry的話就是：“不是沒有什么可添加，而是沒有什么可消減的時(shí)候，才算是達(dá)到了完美?！?/p>
這也使得我們在長時(shí)間休止之后返回項(xiàng)目，以及鼓勵(lì)其他人參與進(jìn)來變得容易多了。
最后優(yōu)化 —— 我們很容易掉入試圖比用戶或計(jì)算機(jī)更聰明，并且預(yù)優(yōu)化各種邊緣情況的陷阱。關(guān)注帕累托法則（80%的效果來自于20%的工作）。寫代碼，運(yùn)行代碼，當(dāng)必要的時(shí)候?qū)Ｗ⒂谧畲蟮钠款i。這也支持保持代碼庫的簡單。
說“不要首先優(yōu)化代碼”并不意味著“編寫粗糙的代碼”。代碼總是應(yīng)該精益和優(yōu)雅，沒有必要畫蛇添足，不要將一整天的時(shí)間用在擠壓剩下的10%，但其實(shí)已經(jīng)能夠工作良好的一些東西上。不但工作效率會(huì)下降，而且還會(huì)引進(jìn)更多復(fù)雜性，解決方案變得不那么可歸納，等等。
著眼于“最重要的事情優(yōu)先”—— 總是有一些項(xiàng)目領(lǐng)域比其他的更有趣或更具挑戰(zhàn)性。工作于那些有趣的東西總是比工作于那些必要的東西更有誘惑。
在攻克重要部分時(shí)，將有趣部分作為一種調(diào)劑，也就是說，兩者都做一點(diǎn)也是可以。
因此，光從這一點(diǎn)上說，將大的問題分解成小問題的理念是不言自明的。每個(gè)人都懂。所以，我會(huì)通過計(jì)分若干“quick wins”來開啟我的一天，這能讓我更有沖勁和更專注（“quick wins”可以是任何東西，包括有趣又小型的挑戰(zhàn)），然后我會(huì)首先沖向“最重要的事情”。
了解全棧 —— 當(dāng)我剛開始干這一行的時(shí)候，沒有什么比等別人做完他們那部分東西，然后我才能繼續(xù)我那部分工作更糟糕的了（設(shè)計(jì)師，后端人員，前端人員，數(shù)據(jù)庫人員，服務(wù)器人員，等等）。
于是，當(dāng)我2000年創(chuàng)辦自己的軟件開發(fā)公司的時(shí)候，我做了一個(gè)明智的決定，那就是涉獵全棧。我知道我不可能擅長所有東西，也不可能是最后唯一對所有一切負(fù)責(zé)的人，但我想要做終端到終端的原型，因?yàn)槲覜]有耐心看過程。
每當(dāng)我需要的東西觸碰到我不懂的領(lǐng)域時(shí)，我會(huì)研究它。于是乎，我學(xué)會(huì)了服務(wù)器管理，數(shù)據(jù)庫管理，設(shè)計(jì)，前端/后端開發(fā)，云架構(gòu)等。
通過了解其他領(lǐng)域是做什么的，我才能寫出包含它們需要的代碼。
當(dāng)然，其中的一些要點(diǎn)似乎并不是所謂的“小習(xí)慣”，但我向你保證，它們是小變化歷經(jīng)20年時(shí)間導(dǎo)致的結(jié)果。重要的行為變化并沒有意義，更多的是關(guān)于我是如何頻繁地練習(xí)這門技術(shù)（在過去10年時(shí)間中每年大概4000-5000個(gè)小時(shí)）。
所以，我的做法更像是去回答這個(gè)問題：“什么樣的小習(xí)慣會(huì)導(dǎo)致更糟糕的軟件和低效的生產(chǎn)力？”，然后反過來。
;){kind=link}